home *** CD-ROM | disk | FTP | other *** search
/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat3 / librw / RWDDEstreambuf.z / RWDDEstreambuf
Encoding:
Text File  |  2002-10-03  |  14.9 KB  |  265 lines

  1.  
  2.  
  3.  
  4. RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                      RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  5.  
  6.  
  7.  
  8. NNNNaaaammmmeeee
  9.      RWDDEstreambuf - Rogue Wave library class
  10.  
  11. SSSSyyyynnnnooooppppssssiiiissss
  12.               #include <rw/winstrea.h>
  13.  
  14.  
  15.  
  16.               #include <iostream.h>
  17.           iostream str( new RWDDEstreambuf(CF_TEXT, TRUE, TRUE, TRUE) ) ;
  18.  
  19.  
  20.  
  21.  
  22. DDDDeeeessssccccrrrriiiippppttttiiiioooonnnn
  23.      Class RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff is a specialized ssssttttrrrreeeeaaaammmmbbbbuuuuffff that gets and puts
  24.      sequences of characters to Microsoft Windows global memory that has been
  25.      allocated with the GGGGMMMMEEEEMMMM____DDDDDDDDEEEESSSSHHHHAAAARRRREEEE flag.  It can be used to exchange data
  26.      through the Windows DDDDyyyynnnnaaaammmmiiiicccc DDDDaaaattttaaaa EEEExxxxcccchhhhaaaannnnggggeeee (DDE) facility.  The class has
  27.      two modes of operation: dynamic and static.  In dynamic mode, memory is
  28.      allocated and reallocated on an as-needed basis.  If too many characters
  29.      are inserted into the internal buffer for its present size, then it will
  30.      be resized and old characters copied over into any new memory as
  31.      necessary.  This is transparent to the user.  It is expected that this
  32.      mode would be used primarily by the DDE server.  In static mode, the
  33.      buffer streambuf is constructed from a specific piece of memory.  No
  34.      reallocations will be done.  It is expected that this mode would be used
  35.      primarily by the DDE client.  In dynamic mode, the RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff "owns"
  36.      any allocated memory until the member function ssssttttrrrr(((()))) is called, which
  37.      "freezes" the buffer and returns an unlocked Windows handle to it.  The
  38.      effect of any further insertions is undefined.  Until ssssttttrrrr(((()))) has been
  39.      called, it is the responsibility of the RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff destructor to free
  40.      any allocated memory.  After the call to ssssttttrrrr(((()))), it becomes the user's
  41.      responsibility.  In static mode, the user always has the responsibility
  42.      for freeing the memory handle.  However, because the constructor locks
  43.      and dereferences the handle, you should not free the memory until either
  44.      the destructor or ssssttttrrrr(((()))) has been called, either of which will unlock the
  45.      handle.  Note that although the user may have the "responsibility" for
  46.      freeing the memory, whether it is the client or the server that actually
  47.      does the call to GGGGlllloooobbbbaaaallllFFFFrrrreeeeeeee(((()))) will depend on the DDE "release" flag.
  48.  
  49. PPPPeeeerrrrssssiiiisssstttteeeennnncccceeee
  50.      None
  51.  
  52. EEEExxxxaaaammmmpppplllleeee
  53.      This is an example of how the class might be used by a DDE server.
  54.  
  55.               #include <rw/winstrea.h>
  56.           #include <iostream.h>
  57.           #include <windows.h>
  58.           #include <dde.h>
  59.           BOOL
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                      RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  71.  
  72.  
  73.  
  74.           postToDDE(HWND hwndServer, HWND hwndClient) {
  75.             RWDDEstreambuf* buf =
  76.             new RWDDEstreambuf(CF_TEXT, TRUE, TRUE, TRUE);
  77.             ostream ostr(buf);
  78.             double d = 12.34;
  79.             ostr << "Some text to be exchanged through the DDE.0;
  80.             ostr << "The double you requested is: " << d << endl;
  81.             ostr.put(0);     // Include the terminating null
  82.             // Lock the streambuf, get its handle:
  83.             HANDLE hMem = buf->str();
  84.             // Get an identifying atom:
  85.             ATOM aItem = GlobalAddAtom("YourData");
  86.             if(!PostMessage(hwndClient, WM_DDE_DATA, hwndServer,
  87.                             MAKELONG(hMem, aItem))){
  88.               // Whoops!  The message post failed, perhaps because
  89.               // the client terminated.  Now we are responsible
  90.               // for deallocating the memory:
  91.              if( hMem != NULL )
  92.              GlobalFree(hMem);
  93.              GlobalDeleteAtom(aItem);
  94.              return FALSE;
  95.             }
  96.             return TRUE;
  97.           }
  98.  
  99.  
  100.      The handle of the DDE server is passed in as parameter hhhhwwwwnnnnddddSSSSeeeerrrrvvvveeeerrrr, the
  101.      handle of the client as parameter hhhhwwwwnnnnddddCCCClllliiiieeeennnntttt.  An oooossssttttrrrreeeeaaaammmm is created,
  102.      using an RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff as its associated ssssttttrrrreeeeaaaammmmbbbbuuuuffff.  The results can be
  103.      used much like any other oooossssttttrrrreeeeaaaammmm, such as ccccoooouuuutttt, except that characters
  104.      will be inserted into Windows global memory, from where they can be
  105.      transferred through the DDE.  Note the parameters used in the
  106.      constructor.  These should be studied below as they have important
  107.      ramifications on how memory allocations are handled through the DDE.  In
  108.      particular, parameter ffffRRRReeeelllleeeeaaaasssseeee, if TTTTRRRRUUUUEEEE, states that the cccclllliiiieeeennnntttt will be
  109.      responsible for deallocating the memory when done.  The defaults also
  110.      specify ffffAAAAcccckkkkRRRReeeeqqqq TTTTRRRRUUUUEEEE, meaning that the client will acknowledge receiving
  111.      the message: you must be prepared to receive it.  Some text and a double
  112.      is inserted into the oooossssttttrrrreeeeaaaammmm.  Member function ssssttttrrrr(((()))) is then called which
  113.      unlocks and returns a Windows HHHHAAAANNNNDDDDLLLLEEEE.  Once we have called ssssttttrrrr(((()))), we are
  114.      responsible for this memory and must either free it when done, or pass on
  115.      that responsibility to someone else.  In this case, it will be passed on
  116.      to the client.  An atom is then constructed to identify the data.  The
  117.      DDE data, along with its identifying atom, is then posted.  If the post
  118.      fails, then we have been unable to foist our responsbility for the global
  119.      memory onto someone else and will have to free it (along with the atom)
  120.      ourselves.
  121.  
  122. PPPPuuuubbbblllliiiicccc CCCCoooonnnnssssttttrrrruuuuccccttttoooorrrrssss
  123.               RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff(WORD cfFormat  = CF_TEXT,
  124.                          BOOL fResponse = TRUE
  125.                          BOOL fAckReq   = TRUE
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                      RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  137.  
  138.  
  139.  
  140.                          BOOL fRelease  = TRUE);
  141.  
  142.  
  143.      Constructs an empty RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff in dynamic mode.  The results can be
  144.      used anywhere any other ssssttttrrrreeeeaaaammmmbbbbuuuuffff can be used.  Memory to accomodate new
  145.      characters will be allocated as needed. The four parameters are as
  146.      defined by the WWWWiiiinnnnddddoooowwwwssss RRRReeeeffffeeeerrrreeeennnncccceeee,,,, VVVVoooolllluuuummmmeeee 2222 (in particular, see the
  147.      section DDDDDDDDEEEE MMMMeeeessssssssaaaaggggeeee DDDDiiiirrrreeeeccccttttoooorrrryyyy).  Parameter ccccffffFFFFoooorrrrmmmmaaaatttt specifies the format
  148.      of the data being inserted into the ssssttttrrrreeeeaaaammmmbbbbuuuuffff.  These formats are the
  149.      same as used by SSSSeeeettttCCCClllliiiippppbbbbooooaaaarrrrddddDDDDaaaattttaaaa(((()))).  If a specializing virtual streams
  150.      class such as RRRRWWWWbbbboooossssttttrrrreeeeaaaammmm or RRRRWWWWppppoooossssttttrrrreeeeaaaammmm is used to perform the actual
  151.      character insertions instead of a simple oooossssttttrrrreeeeaaaammmm, the format may not be
  152.      so simple.  In this case, the user might want to register his or her own
  153.      format, using the Windows function RRRReeeeggggiiiisssstttteeeerrrrCCCClllliiiippppbbbbooooaaaarrrrddddFFFFoooorrrrmmmmaaaatttt(((()))).  For the
  154.      meaning of the other three parameters see below, and/or the WWWWiiiinnnnddddoooowwwwssss
  155.      reference manuals.
  156.  
  157.               RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff(HANDLE hMem);
  158.  
  159.  
  160.      Constructs an RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff in static mode, using the memory block with
  161.      global handle hhhhMMMMeeeemmmm.  The effect of gets and puts beyond the size of this
  162.      block is unspecified.  The format of the DDE transfer, and the specifics
  163.      of DDE acknowledgments, memory allocations, eeeettttcccc...., can be obtained by
  164.      using the member functions defined below.
  165.  
  166. PPPPuuuubbbblllliiiicccc DDDDeeeessssttttrrrruuuuccccttttoooorrrr
  167.               ~RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff();
  168.  
  169.  
  170.      If member function ssssttttrrrr(((()))) has not been called, the destructor unlocks the
  171.      handle and, if in dynamic mode, also frees it.
  172.  
  173. PPPPuuuubbbblllliiiicccc MMMMeeeemmmmbbbbeeeerrrr FFFFuuuunnnnccccttttiiiioooonnnnssss
  174.      Because RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff inherits from ssssttttrrrreeeeaaaammmmbbbbuuuuffff, any of the latter's
  175.      member functions can be used.  Furthermore, RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff has been
  176.      designed to be analogous to ssssttttrrrreeeeaaaammmmbbbbuuuuffff.  However, note that the return
  177.      type of ssssttttrrrr(((()))) is a HHHHAAAANNNNDDDDLLLLEEEE, rather than a cccchhhhaaaarrrr****.
  178.  
  179.               BOOL
  180.           aaaacccckkkkRRRReeeeqqqq() const;
  181.  
  182.  
  183.      Returns whether this DDE exchange requests an acknowledgement.  See the
  184.      WWWWiiiinnnnddddoooowwwwssss RRRReeeeffffeeeerrrreeeennnncccceeee,,,, VVVVoooolllluuuummmmeeee 2222, for more information.
  185.  
  186.               WORD
  187.           ffffoooorrrrmmmmaaaatttt() const;
  188.  
  189.  
  190.      Returns the format of this DDE exchange (eeee....gggg...., CCCCFFFF____TTTTEEEEXXXXTTTT for text exchange,
  191.      eeeettttcccc.).  See the WWWWiiiinnnnddddoooowwwwssss RRRReeeeffffeeeerrrreeeennnncccceeee,,,, VVVVoooolllluuuummmmeeee 2222, for more information.
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))                                      RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff((((3333CCCC++++++++))))
  203.  
  204.  
  205.  
  206.               BOOL
  207.           rrrreeeelllleeeeaaaasssseeee() const;
  208.  
  209.  
  210.      Returns TTTTRRRRUUUUEEEE if the client is responsible for the release of of the
  211.      memory returned by ssssttttrrrr(((()))).  See the WWWWiiiinnnnddddoooowwwwssss RRRReeeeffffeeeerrrreeeennnncccceeee,,,, VVVVoooolllluuuummmmeeee 2222, for more
  212.      information.
  213.  
  214.               BOOL
  215.           rrrreeeessssppppoooonnnnsssseeee() const;
  216.  
  217.  
  218.      Returns TTTTRRRRUUUUEEEE if this data is in response to a WWWWMMMM____DDDDDDDDEEEE____RRRREEEEQQQQUUUUEEEESSSSTTTT message.
  219.      Otherwise, it is in response to a WWWWMMMM____DDDDDDDDEEEE____AAAADDDDVVVVIIIISSSSEEEE message.  See the WWWWiiiinnnnddddoooowwwwssss
  220.      RRRReeeeffffeeeerrrreeeennnncccceeee,,,, VVVVoooolllluuuummmmeeee 2222, for more information.
  221.  
  222.               HANDLE
  223.           ssssttttrrrr();
  224.  
  225.  
  226.      Returns an (unlocked) HHHHAAAANNNNDDDDLLLLEEEE to the global memory being used.  The
  227.      RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff should now be regarded as "frozen": the effect of
  228.      inserting any more characters is undefined.  If the RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff was
  229.      constructed in dynamic mode, and nothing has been inserted, then the
  230.      returned HHHHAAAANNNNDDDDLLLLEEEE may be NNNNUUUULLLLLLLL.  If it was constructed in static mode, then
  231.      the returned handle will be the handle used to construct the
  232.      RRRRWWWWDDDDDDDDEEEEssssttttrrrreeeeaaaammmmbbbbuuuuffff.
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.